Internet protocol (IP) telephones used for Internet telephony via signaling protocols such as, H.323 or Session Initiation Protocol (SIP), already exist in the prior art. Although these signaling protocols may make some provisions for additional functionality, such as multiparty conferencing with other SIP and H.323 devices, they do not take advantage of the powerful existing functionality already found within most private branch exchange (PBX) systems. PBX systems provide such functionality as automatic call distribution, messaging, voice mail, conferencing, call hold, dial-by-name, and the like. Existing Internet telephony signaling protocols do not include specific provisions for accessing such PBX functionality. Specifically, signaling protocols such as H.323 and SIP have been designed to work without the use of a PBX.
The existence of Computer Telephony Integration (CTI) technology does not aid in providing PBX functionality to IP phones. Generally speaking, CTI is a technology through which computers add intelligence to telephone networks. CTI is typically applied to a personal computer (PC) with an associated standard telephone to access the functionality of a PBX. A CTI client resident within the PC typically exploits functionality residing within the PC, such as ActiveX, OLE, dlls, and the like, to access the PBX functionality. For example, a call may be initiated by clicking a name in a contact management PC program instead of dialing the number on the telephone.
FIG. 1 is a schematic block diagram of a traditional CTI system conventional in the art. The system includes a CTI-enabled desktop 10 including a PC and a traditional telephone set 14. A software application 18 resident in the PC 12 is used to access a functionality provided by a PBX 20 via a CTI client 16 also resident in the PC. The CTI client transmits commands to a CTI server 22 via an internet protocol (IP) network 24 associated with the accessed functionality. The CTI server 22 receives the CTI commands from the PC 12, translates them to PBX commands, and transmits the PBX commands to the PBX for invoking an action on the PBX 20. Communication ensues with the telephone set 14 via the PBX 20 over a telephone network 26. Existing CTI architectures, however, are not applicable to IP telephones.
One approach in allowing IP phones to utilize the existing PBX functionality is PBX redesign. PBX redesign exposes the internal features of the PBX to vendor-specific IP phones, allowing IP phones to interact directly with the PBX without intermediate servers. Unfortunately, PBX redesign and vendor-specific IP phones have the following limitations. First, with PBX redesign, an enterprise may be generally forced to only use the vendor-specific IP phone with the vendor-specific PBX. As such, customer choice may be eliminated, severely impacting an enterprise migration plan. For example, an enterprise may have multiple types of PBXs and may wish to decouple the choice of the IP phone from the types of existing or future PBX systems.
Second, with PBX redesign, many of the vendor-specific IP phones may be able to make/place calls to/from the PBX itself, but not from other standardized IP phones and IP voice gateways. Third, for the vendor to make changes to the internal PBX system, the PBX system may have to be modified to expose the functionality to IP clients. This may require substantial development effort on the part of the vendor and may further require each enterprise to install the modified PBX system.
Consequently, what is needed is a solution that exposes the PBX functionality that is typically associated with custom vendor digital sets or CTI-based PC desktop applications to IP phone clients. Specifically, a solution is needed that enhances IP phone clients with powerful functionality already resident within many existing PBX systems.